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EVALUATION 

• The  feasibility  and  value  of  code  auditing  to  enforce  programming 
standards  have  been  successfully  demonstrated.  Most  major  software  develop- 
ment projects  have  some  form  of  programming  standards,  but  rarely  are  they 
enforced,  and  then  not  effectively.  Such  standards  generally  address  four 
areas : 

* Documentation  - the  placement,  orientation,  and  amount  of  comments 
in  a program 

* Format  - the  placement  and  grouping  of  code  elements 

* Design  - the  use  of  language  constructs,  program  structure,  and  module 
size 

* Structural  - use  of  top-down  design  and  implementation 

> 

The  purpose  of  programming  standards  is  to  make  program  modules,  coded 
by  various  people,  more  uniform,  readable,  and  understandable;  to  make  them 
easier  to  debug,  test,  and  maintain;  and  to  restrict  the  use  of  coding 
practices  which  experience  has  shown  to  be  prone  to  error.  Especially,  pro- 
gramming standards  define  what  is  good  programming  practices. 

RADC's  Code  Auditor,  an  automatic  test  tool,  will  be  used  for  the  cost 
effective  enforcement  of  FORTRAN  programming  standards  and  conventions 
appropriate  to  the  Air  Force  software  environment.  The  single  biggest  ad- 
advantage  of  favoring  an  automated  auditor  over  manual  methods,  besides  its 
cost  effectiveness,  is  its  complete  objectiveness  and  unambiguity. 

DONALD  L.  MARK 
Project  Engineer 
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1.0  GENERAL  DESCRIPTION 


1.1  Purpose  of  the  User's  Manual 

The  purpose  of  this  User's  Manual  is  to  describe  the  use  and 
operation  of  the  RADC  FORTRAN  Code  Auditor.  The  Code  Auditor, 
an  automated  test  tool,  is  used  for  the  cost  effective  enforce- 
ment of  FORTRAN  programming  standards  and  conventions  appropriate 
to  the  Air  Force  software  environment.  It  does  not  modify  code. 
Using  pre-defined  coding  standards  and  conventions,  it  simply 
advises  the  user  where  these  standards  and  conventions  have  not 
been  adhered  to.  The  single  biggest  advantage  favoring  an 
automated  auditor  over  manual  methods,  besides  its  cost 
effectiveness,  is  its  complete  objectiveness  and  unambiguity. 

The  standards  can  be  viewed  as  being  coding  enforcements  in  four 
areas: 

(1)  Documentation  Standards  - Standards  defining  quantity 
and  placement  of  commentary  thus  enhancing  program 
readability  and  comprehension. 

(2)  Format  Standards  - Standards  identifying  physical 
placement  and  grouping  of  code  elements  on  the  coding 
sheet,  again  enhancing  readability  and  comprehension. 

(3)  Design  Standards  - Standards  limiting  module  size  and 
placing  restrictions  on  the  use  of  certain  instructions 
with  the  end  result  of  providing  an  optimization  of 
code  relative  to  execution  time. 
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(4)  Structural  Standards  - Standards  requiring  the  use  of 
strict  rules  for  the  top-down  design  and  implementation 
of  a system  of  programs  and  the  requirement  that  the 
components  adhere  to  a hierarchical  form  as  much  as 
possible. 


1.2  Project  Reference 


(1)  Control  Cards  Reference  Manual 

Order  Number  BS19 

(2)  File  Management  Supervisor 

Order  Number  DB54 

(3)  Fortran  IV 

Order  Number  BN88 

(4)  GCOS  Time-Sharing  Terminal/Batch  Interface  Facility 

Order  Number  BR99 

(5)  General  Comprehensive  Operating  Supervisor 

Order  Number  BR43 

(6)  General  Loader 

Order  Number  BN90 

(7)  Guidelines  for  Software  Quality  Assurance 

TRW  Number  SPD-3055 
Date  9-75 
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2.0 


SYSTEM  SUMMARY 


2.1  System  Application 

The  RADC  FORTRAN  Code  Auditor  Program  provides  project  personnel 
with  an  automatic  means  of  auditing  their  computer  programs  to 
insure  that  the  programming  practices  contained  within  their  oro- 
grams  conform  to  RADC  Software  Coding  Standards  and  Procedures. 

These  programming  standards  a "e  described  in  Appendix  A.  The  RADC 
FORTRAN  Code  Auditor  also  monitors  the  user's  source  to  determine 
if  the  code  is  structured,  i.e.,  consists  of  combinations  of  the 
control  structures  depicted  in  Appendix  B,  such  that  control  flows 
from  top  to  bottom  or  from  beginning  to  end. 

2.2  System  Operation 

The  RADC  FORTRAN  Code  Auditor  is  initially  used  by  the  programmer 
during  program  development  and  only  after  successful  compilation  to 
identify  those  areas  within  his  code  which  do  not  adhere  to  the  pre- 
defined coding  standards  and  conventions.  Utilization  of  the  tool 
during  the  program  development  stage  allows  the  programmer  to  con- 
currently reduce  or  eliminate  any  standards  violations  prior  to 
unit  testing  and  quality  assurance  examinations.  The  latter  activity 
also  makes  use  of  the  Code  Auditor  in  officially  sanctioning  the  pro- 
gram's adherence  to  established  coding  conventions.  Figure  2-1  in 
general,  depicts  the  timing  of  the  application  of  the  Code  Auditor 
during  the  software  development  cycle.  The  Code  Auditor  has  been 
designed  such  that  its  output  is  clear  and  unambiguous  thus  enabling 
its  use  by  both  technical  and  management  personnel. 
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2.3  System  Configuration 


The  minimum  configuration  required  to  support  the  RADC  FORTRAN 
Code  Auditor  shall  include: 

1.  Honeywell  Series  600/6000  Information  Processing  System 
under  GC0S  control 

2.  40K  words  of  memory 

3.  DSS180  Disk  Storage  Subsystem  or  the  equivalent;  a 
minimum  of  1 drive 

4.  36  - bit  word  length 

5.  Card  Reader  - Reads  punched  80  column  cards  (CRZ-201  or 
equi valent) 

6.  Line  Printer  - Prints  132  columns  per  line  (PRT  300/PRT 
201  or  equivalent) 

7.  Software  - FORTRAN  Y Compiler  (Honeywell  Extended  Compiler) 
2.4  System  Organization 

The  Code  Auditor  consists  of  three  physical  segments  (overlays) 
which  are  functionally  consistent  with  the  three  basic  logical 
components  of  the  system  and  their  attendant  operation.  The 
operations  performed  by  the  Code  Auditor's  logical  parts  and  their 
correlation  to  the  appropriate  physical  system  overlays  are: 

(1)  Analyze  the  user's  source  code  to  check  for  non-adherence 
to  the  established  standards  and  conventions  except  the 
program's  structural  requirements,  reporting  any  non-confor- 
mance monitored.  Overlay  A performs  this  function  com- 
pletely independent  of  overlays  B and  C processing. 
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(2)  Overlay  B performs  a second  pass  analysis  of  the  user's 
source  code,  parsing  its  structure  into  segments  and 
relationships  among  segments,  for  subsequent  orocessing 
by  overlay  C.  The  Segment  Transfer  Table,  which  des- 
cribes this  interrelationship  among  the  program's  seg- 
ments, is  written  to  a temporary  disk  file  and  consti- 
tutes the  single  interface  between  overlays  B and  C- 

(3)  Overlay  C accents  as  input  the  temporary  file  created 

in  overlay  B containing  the  Segment  Transfer  Table.  Via 
iterative  application  of  the  reduction  algorithm  dis- 
cussed in  Appendix  B,  an  analysis  is  made  of  the  Segment 
Transfer  Table  to  establish  compliance  with  the  structured 
programming  rules.  This  overlay  prints  the  Segment  Trans- 
fer Table  as  passed  from  overlay  B,  its  contents  after 
iterative  reduction  (if  unstructured),  and  summarily  a 
"structured/unstructured"  message  for  each  module  of  the 
user's  source  modules  processed. 

Figure  2-2  depicts  for  each  logical  segment,  its  interface  with 
other  segments,  files  processed  and  reports  generated.  The  main 
driver  (root  segment)  is  interfaced  via  a labeled  common  to  each  of 
the  three  overlays  comprising  the  Code  Auditor  system.  Besides 
providing  root  segment  access  to  Code  Auditor  files , the  labeled 
common  block  passes  option  card  parameters  for  execution  control  of 
the  individual  overlays. 
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Figure  2.2.  Code  Auditor  Organization  and  Interfaces 
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2.5  Performance 

2.5.1  Input  Limits 

The  Code  Auditor  will  process  user  source  input  from  any  input 
medium;  cards,  disk  or  tape.  Each  source  statement  must  conform 
to  an  80-column  card  image  record  irrespective  of  the  input 
medium.  The  maximum  number  of  input  modules  (main  programs, 
function  subproarams,  statement  functions,  or  subroutines)  pro- 
cessed by  the  Code  Auditor  is  100. 

2.5.2  Output  Limits 

Other  than  the  temporary  disk  file  output  from  overlay  B,  there 
are  no  limits  to  Code  Auditor  output.  The  disk-resident  Segment 
Transfer  Table,  output  by  overlay  B,  is  bound  by  table  capacity 
internal  to  overlay  B.  Translation  of  table  limits  to  input  file 
size  is  not  possible  since  table  overflow  is  dependent  upon  the 
input  source's  logical  structure,  rather  than  the  volume  of  input. 

2.5.3  Processing  Time 

Reasonable  estimates  of  program  processing  time  can  be  made  by 
using  the  base  time  of  approximately  .15  seconds  of  processing 
time  per  input  card  image  processed. 

2.5.4  Other  Limits 

Additional  limitations  and  constraints  to  source  content  follow: 

(1)  FORTRAN  syntax  errors  are  not  detected  by  the  Code  Auditor. 
In  order  for  Code  Auditor  to  audit  properly,  all  syntax 
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errors  detectable  by  the  compiler  should  be  absent  from 
the  input. 

A b^ank  character  (hollerith  blank)  is  recognized  as  a 
delimiter;  therefore,  embedded  blanks  within  variable 
names,  keywords,  etc.,  will  cause  an  incorrect  scan  of 
the  elements  in  the  card  image. 

When  the  programmer  includes  an  IMPLICIT  statement  in  the 
program  specifying  alphabetic  characters  as  being  either 
INTEGER  or  DOUBLE  PRECISION  variable  types,  and  subsequently 
uses  a specification  statement  redefining  the  implicity 
defined  variable  to  something  other  than  DOUBLE  PRECISION 
or  INTEGER  variable  type,  the  Code  Auditor  will  not  deter- 
mine that  standard  no.  14  for  mixed  mode  arithmetic  or 
standard  no.  22  for  I/O  device  referenced  as  an  integer 
name  has  been  violated. 

When  the  Code  Auditor  encounters  a comment  card  imbedded 
within  continuation  cards,  data  on  the  remaining  continua- 
tion cards  are  not  analyzed  for  adherence  to  the  pre-defined 
coding  standards. 

Variable  or  array  names  contained  within  labeled  common  and 
additionally  declared  as  CHARACTER  may  cause  improper  moni- 
toring of  standard  no.  24;  common  block  length  must  be  the 
same  in  all  modules. 


GENERAL  DESCRIPTION  OF  INPUTS,  PROCESSING  AND  OUTPUTS 


Inputs 

The  Code  Auditor  inputs  consist  of  the  user's  input  source 
code  and  one  or  more  option  cards. 

User's  Source  Input 

The  Code  Auditor's  source  input  may  be  input  via  either  of 
three  mediums;  cards,  disk  or  tape.  Irrespective  of  the 
input  medium,  all  source  statements  must  be  80-column  card- 
imaae  format.  The  source  code  input  may  constitute  any 
number  of  FORTRAN  modules,  up  to  100,  delimited  in  the  usual 
manner  by  the  FORTRAN  END  Card. 

Option  Card  Input 

The  option  card  provides  the  user  with  a method  of  directing 
the  Code  Auditor  to  execute  optional  or  alternate  functions 
of  the  Code  Auditor.  It  may  only  be  input  from  the  card 
reader.  The  optional  functions  supported  are: 

(1)  List  the  entire  input  source  code  along  with  Code 
Auditor  assioned  card  sequence  numbers  and  indi- 
cators showing  non-adherence  to  coding  standards. 

(2)  Limit  the  output  listing  of  the  input  source  code 
to  those  card  images  containing  source  code  where 
non-adherence  occurs  along  with  assianed  card  num- 
bers and  indicators. 
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(3)  Suppress  auditing  for  adherence  to  any  one  or 
more  of  the  coding  standards. 

(4)  Suppress  auditing  for  all  of  the  coding  standards, 
nos.  1 thru  37. 

(5)  Suppress  auditing  for  adherence  to  program 
structural  requirements. 

(6)  The  input  source  is  realtime  code. 

These  controls  are  input  on  the  option  card.  The  option 
card  is  identified  by  the  character  string  "CAOPTION"  in  card 
columns  1 through  8.  Other  parameters  may  appear  in  any  se- 
quence. When  the  Code  Auditor  encounters  no  CAOPTION  card 
at  the  start  of  execution,  the  Code  Auditor  will  provide 
default  options  as  follows: 

(1)  List  the  entire  source  input. 

(2)  Audit  for  adherence  to  all  non-realtime  coding 
standards. 

(3)  Audit  for  adherence  to  structural  programing 
requirements. 

The  parameter  character  strings  which  control  the  options 
and  their  effect  on  Code  Auditor  processing  are  shown  in 
the  list  below. 
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Parameter 

Character 

String 

CAOPTION 

LIST 

NOLIST 

REAL 

NOCA 

NOSTRUCT 

1 

2 


Effect  on  Code  Auditor  Processing 

Directs  Code  Auditor  to  search  the  card 
for  user  controls. 

Directs  Code  Auditor  to  list  the  entire 
source  code  input. 

Directs  Code  Auditor  to  limit  the  source 
code  listing.  (Note:  When  Code  Auditor 

finds  neither  the  parameter  LIST  nor 
NOLIST  the  default  is  LIST.  When  Code 
Auditor  finds  both  parameters  LIST  and 
NOLIST  the  default  is  NOLIST.) 

Directs  Code  Auditor  to  refrain  from 
auditing  for  adherence  to  the  coding 
standard  numbers  27  and  28. 

Directs  Code  Auditor  to  refrain  from 
auditing  for  adherence  to  coding  stan- 
dard nos.  1 thru  37. 

Directs  Code  Auditor  to  refrain  from 
auditing  for  adherence  to  structural 
coding  requirements. 

Directs  Code  Auditor  to  refrain  from 
auditing  for  adherence  to  coding  stan- 
dard number  1 . 

Directs  Code  Auditor  to  refrain  from 
auditing  for  adherence  to  coding  stan- 
dard number  2. 


Directs  Code  Auditor  to  refrain  from 
auditing  for  adherence  to  coding  stan- 
dard number  37.  (Note:  Each  of  the 

numbers  from  1 to  37  is  a control  para- 
meter. Each  number  n Input  directs  Code 
Auditor  to  refrain  from  auditing  for  ad- 
herence to  coding  standard  number  n.) 


The  CAOPTION  card  is  identified  to  Code  Auditor  by  the 
string  of  characters  "CAOPTION"  in  columns  1-8  of  the 
card.  Other  parameters  may  appear  in  any  sequence.  The 
parameters  are  delimited  by  a string  of  one  or  more  cha- 
racters of  blanks  and/or  commas  in  any  sequence. 

3.2  Code  Auditor  Outputs 

All  of  Code  Auditor's  outputs  are  printed  data.  Code 
Auditor  prints  during  eight  distinct  phases  of  its  execu- 
tion; four  phases  each  for  coding  standards  audit  and  pro- 
gram structural  analysis  respectively.  The  first  four  phases 
of  printed  output  occur  during  coding  standards  audit  pro- 
cessing. Phases  five  through  eight  occur  during  proaram 
structural  analysis  processing.  Code  Auditor  outputs  are 
described  in  sections  3.2.1  through  3.2.7. 

3.2.1  Initialization  Output  (Coding  Standards  Audit) 

There  are  two  initialization  messages.  The  first  message 
reflects  Code  Auditor's  Interpretation  of  options  selected 
by  the  user.  It  reports  the  user's  direction  to  Code  Auditor 
with  respect  to  the  options  NOLIST  and  REAL. 

The  second  message  is  a list  of  the  standards  (see  figure  3-1). 

3.2.2  Module  Audit  Output  (Coding  Standards  Audit) 

The  data  output  during  the  audit  of  each  module  are  the 
listing  of  the  source  code  being  audited,  the  Code  Auditor 


-13- 


* 


assigned  card  sequence  numbers,  and  numeric  codes  indicating 
which  standards  were  violated.  A maximum  of  five  numeric 
codes  are  printed  per  source  statement.  Figure  3-2  shows 
a sample  of  this  output. 

3.2.3  Module  Summary  Output  (Coding  Standards  Audit) 

Following  the  audit  of  each  module.  Code  Auditor  prints 
messages  showing  the  count  of  executable  statements  in  the 
module  in  addition  to  the  number  of  FORTRAN  IF  statements. 
Following  is  a list  of  FORTRAN  statements  included  in  the 
count  of  executable  statements: 


DO 

PUNCH 

GO  TO 

PRINT 

IF 

DECODE 

PAUSE 

ENCODE 

STOP 

READ 

REWIND 

WRITE 

BACKSPACE 

ASSIGN 

ENDFILE 

Assignment  statements 

CALL 

Function  calls 

EXIT 

RETURN 

Code  Auditor  also  outputs  a table  summarizing  the  results 
of  the  audit  of  the  module.  It  is  shown  in  figure  3-3. 

The  numeric  codes  and  descriptions  on  the  left  of  the  tables 
identify  the  standards  not  adhered  to  in  the  module.  The 
"total  errors"  column  contains  counts  of  violations  for  each 
of  the  standards  identified.  The  "card  numbers"  column 
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lists  the  Code  Auditor  assigned  card  numbers  where  the 
corresponding  standard  has  not  been  adhered  to.  A maxi- 
mum of  five  (5)  card  numbers  are  listed  for  each  violated 
standard. 

3.2.4  Program  Summary  Output  (Coding  Standards  Audit) 

Following  audit  of  all  modules  and  following  printout  of 
the  summary  data  for  the  last  module  audited.  Code  Auditor 
prints  three  tables  containing  summary  data  for  module 
audited.  Examples  of  the  three  tables  appear  in  figures 
3-4  through  3-6  following. 

Subroutine  "SUB1 " has  3 instances 
of  non-adherence  to  standard  no.  3 

ROUTINE  RESTRICTION 

1 23456789  10  11... 

CAREG  2 3 3 1 0 1 2 0 13  1 0... 

SUB!  02300010  30  0... 

Figure  3-4,  Program  Summary  Output 
(Error  Summary) 


The  Code  Auditor  Error  Summary  Report  (figure  3-  4)  has  one 
entry  for  each  routine  audited  for  each  of  the  37  standards. 


ROUTINE 

TOTAL  ERRORS 

TOTAL  CARDS 

PERFORMANCE  INDEX 

CAREG 

60 

153 

60.78 

SUB! 

17 

53 

67.92 

TOTALS 

77 

206 

62.62 

Figure  3-5,  Program  Summary  Output 
(Error  Totals) 

The  Error  Totals  table  (figure  3-5)  has  one  line  of  data  for 
each  routine  audited  plus  the  line  of  data  for  the  totals. 

The  performance  index  is 

(’  - total  'cards')  x 100>  a arade  frm  2er0  t0  ,0°- 

When  the  performance  index  is  calculated  to  be  less  than  zero 
Code  Auditor  outputs  a value  of  zero. 
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STANDARDS  VIOLATION  TOTALS 

RESTRICTION  1 23456789  10  11... 

TOTAL  006000000  0 0... 

There  are  6 instances  of  non-adherence  to 
coding  standard  number  3 in  the  routine 
audited. 


Figure  3-6,  Program  Summary  Output 
(Standards  Violation  Totals) 

The  Standards  Violations  Totals  table  has  one  entry  per 
standard  1 through  37. 

3.2.5  Module  Segmentation  Output  (Program  Structural  Analysis) 

Following  the  auditing  of  the  user's  program  for  adherence 
to  the  RADC  coding  standards,  the  program’s  logical  struc- 
ture is  examined.  Appendix  B describes  Code  Auditor's  ap- 
proach in  checking  the  user's  source  code  for  conformance  to 
program  structural  requirements.  The  segmentation  data  printed 
consists  of  a listing  of  the  source  code  being  audited,  anno- 
tated in  the  left  margin  with  Code  Auditor  assigned  segment 
identification  codes.  The  numeric  codes  assigned  are  se- 
quentially ordered  from  the  initial  source  statement  of  a 
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program  module  to  the  last  statement.  The  numeric  segment 
identifiers  are  not  reinitialized  if  more  than  one  module 
is  processed;  the  initial  seqment  number  assigned  for  an 
intermediate  module  is  one  greater  than  the  last  assigned 
segment  number  for  its  predecessor  module.  Figure  3-7 
following  depicts  a sample  of  this  printout. 

.6  Segment  Transfer  Table  Output  (Program  Structural  Analysis) 

The  Segment  Transfer  Table,  depicting  the  logical  transfer 
of  control  among  the  program  module's  segments  (3.2.5)  is 
printed  during  this  phase  of  output.  Each  Segment  Transfer 
Table,  comprised  of  ordered  pairs  of  "from-to"  segment  iden- 
tification codes,  corresponds  on  a one-to-one  basis  with 
each  program  module  processed.  Tracing  throuah  the  Seqment 
Transfer  Table  should  provide  a string  of  segment  identifi- 
cation codes  for  each  logical  path  through  the  corresponding 
program  module.  In  the  Segment  Transfer  Table  of  figure  3-8, 
the  two  logical  paths  through  the  sample  Segment  Transfer 
Group  are  31-32-34-35  and  31-33-35  respectively.  This  figure 
corresponds  to  the  executable  instructions  and  assigned  seg- 
ment identification  codes  for  the  sample  segment  identifica- 
tion group  depicted  in  figure  3-7.  An  example  interpretation 
of  the  Segment  Transfer  Table  follows.  If  the  decision  por- 
tion (ISEG1.EQ.1)  of  the  preceding  IF  expression  is  'TRUE', 
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control  is  transferred  to  segment  number  32  (GO  TO  100)  as 
indicated  by  the  'from-to'  pair  '31-32',  otherwise  control 
passes  to  segment  number  33  as  indicated  by  the  !from-to' 
pair  '31-33'. 

3.2.7  Module  Summary  Output  (Program  Structural  Analysis) 

Each  Segment  Transfer  Table  is  iteratively  reduced  as 
described  in  Appendix  B,  in  making  a determination  of  the 
corresponding  module's  conformance  to  program  structural 
requirements.  Figure  3-9  depicts  a Segment  Transfer  Table 
after  iterative  reduction  for  a typical  unstructured  program. 
Also  printed  during  this  phase  is  a message  declaring  the 
corresponding  module  as  'structured'  as  shown  in  figure  3-8, 
or  'unstructured'  as  depicted  in  figure  3-9. 

The  final  phase  of  Code  Auditor's  printed  output  summarizes 
the  result  of  program  structural  analysis,  as  shown  in 
figure  3-10. 
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3.2.8  Error  Messages 

In  addition  to  its  normal  printed  output,  the  Code  Auditor 
prints  a number  of  error  messages.  Many  of  the  error  messages 
printed  are  simply  a result  of  sanity  checks  performed  by  the 
Code  Auditor  that  suggests  the  user's  source  input  is  not 
compilable.  Others  are  due  to  excessive  module  size  causing 
Code  Auditor's  internal  tables  to  overflow  while  the  remaining 
messages  are  usually  a result  of  logical  errors  not  detectable 
at  compile  time.  In  any  event,  user  response  recommendations  are 
provided  for  each  error.  Should  the  recommended  corrective 
actions  not  clear  the  problem,  the  Code  Auditor  maintenance 
programmer  should  be  consulted.  A brief  explanation  of  each 
error  message  plus  recommended  user  response  follow.  Some  error 
messages  are  grouped  as  a unit  due  to  similarity  in  content  and 
corrective  action. 

(1)  Error  Message 

Description 


Corrective  Action 


A 


- MORE  THAN  100  TASKS 

- The  Code  Auditor  can  process  a 
maximum  of  100  modules  (main 
programs,  subroutines,  function 
subprograms,  etc.)  per  execution. 
Excessive  modules  cause  an  abort. 

- Break  the  source  input  into  groups 
of  100  or  less  modules  and  process 
each  group  in  separate  executions. 
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(2)  Error  Messages  (a) 

(b) 


(c) 

(d) 

(e) 


XXX  OVERFLOW  - ABORT  RUN 
CODE  AUDITOR  VARIABLE  TABLE 
LENGTH  EXCEEDED. .. .SEE  PRO- 
GRAMMER 

VSTR  RATIO  LESS  THAN  ONE 
ERROR  - TOO  MANY  SEGBF  ENTRIES 
TABLE  OVERFLOW  - THIS  RUN 
CONTAINS  XX  TRANSFERS 


Description 


Corrective  Action 


- All  of  the  above  messages 
indicate  the  overflow  of 
various  tables  internal  to  the 
Code  Auditor  and  may  all  be 
attributed  to  excessive  module 
size. 

- Remove  the  offending  module  and 
consider  its  redesign  and  parceling. 

In  all  likelihood  the  module  violates 

coding  standard  No.  6;  maximum  of 

100  executable  statements  per 

module. 


(3)  Error  Messages  (a)  - CLEANUP  - FATAL  ERROR  - SEGMENT  xx 

FROM  SEGBT  IS  GREATER  THAN  ALL 
SEGTAB  ENTRIES 

(b)  - CLEANUP  - FATAL  ERROR  - LABEL  xx 

NOT  FOUND  IN  SEGTAB  TABLE 
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(c) 


(d) 


Descri ption 


Corrective  Action 


INITSG  ERROR  - NAME  xxx 
NOT  IN  KTABLE 

**ERR0R**  UNSOLVABLE  PROBLEM 
IN  TRAPIT 

These  errors  are  most  likely 
logical  errors  not  detected 
at  compile  time. 

Check  logical  program  structure 
after  recompiling. 


(4)  Error  Messages  (a)  - ERROR  DETECTED  BY  IFCK 

I FCK  ERROR  1 

MATCHING  PARENTHESES  WERE  NOT 
FOUND 

(b)  - ERROR  DETECTED  BY  SQZB 

SQZB  ERROR  2 

0 PRECEDES  THE  HOLLERITH  STRING 


Description  - These  errors  detected  as  a result 

of  sanity  checks  conducted  by  the 
Code  Auditor,  and  usually  indicate 
the  source  input  is  not  compilable. 

Corrective  Action  - Recompile  prior  to  processing  thru 

Code  Auditor  again. 


-29- 


3.3 


Operating  Procedures 


The  Code  Auditor  was  designed  to  execute  in  a Honeywell  600/6000 
batch  environment  under  GC0S  control.  Three  control  card  decks 
are  described  for  executing  the  Code  Auditor  under  6C0S.  Each 
deck  corresponds  to  one  of  the  three  alternative  input  mediums 
on  which  the  user's  source  code  may  reside.  The  following  common 
rules  apply  to  all  control  cards: 

(1)  All  control  cards  except  the  ***E0F  card  are 
identified  by  a $ in  card  column  1. 

(2)  The  control  card  name  (i.e.,  IDENT,  LIMITS,  TAPE,  etc.) 
begin  in  card  column  8. 

(3)  The  variable  field  begins  in  card  column  16  and  must 
not  exceed  column  72. 

(4)  Variables  must  be  separated  by  a comma. 

(5)  A blank  terminates  the  field  definition  and  the  card 
scan.  Therefore,  no  embedded  blanks  are  permitted. 

(6)  Upper  case  alphabetic  entries  are  required;  lower  case 
are  user/installation  supplied  data. 
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Source  Input  via  Cards 


The  control  card  sequence  below  shows  the  deck  structure  necessary 
to  execute  with  source  input  from  cards. 


Control  Card 

$ IDEM  account  no. , 
identi fication 


$ USERID  system  master 

catalog  name 

$ EXECUTE  DUMP 


Description 

Identifies  the  user  of  a job 
and  supplies  the  user's  account 
no.  The  variable  field  format 
and  content  is  installation 
dependent. 

Identifies  the  Code  Auditor 
system's  master  catalog  name. 

The  variable  field's  format  and 
content  is  installation  dependent. 

Requests  the  loading  and  sub- 
sequent execution  of  the  Code 
Auditor  program.  Should  the 
execution  activity  terminate 
abnormally,  the  DUMP  parameter  in 
the  variable  field  request  a slave 
core  dump. 
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Control  Card 

LIMITS  05,  40K, 
9K,  5K 


PRMFL  H*,  permit, 
mode,  file  string 


Description 

Modifies  the  default  resource 
limits.  Interpretation  of  the 
variable  field  parameters  follow: 

05  the  maximum  processor  run 

time  is  5 minutes. 

40K  the  maximum  core  storage 

for  running  the  Code  Auditor 
is  40K  words. 

9K  the  amount  of  core  storage 

that  can  be  shared  with  the 
General  Loader  when  the 
Code  Auditor  is  loaded  is 
9K  words. 

5K  the  maximum  number  of 

lines  to  be  written  on 
SYSOUT  during  program 
execution  is  5K  lines. 

Accesses  a permanent  file  where 
the  relocatable  object  code  for 
the  Code  Auditor  resided.  Variable 


field  entries  are  installation 


Control  Card 


Description 


$ FILE  11,  A3RR,  1L 


$ DATA  05 


CAOPTION  parameters 


$ DATA  1 3 


User's  Source  Code 


$ SYSOUT  06 


$ ENDJOB 


Sets  up  allocation  of  a mass 
storage  file.  The  logical  unit 
designator  is  11. 

Indicates  that  program  input  data 
immediately  follows  this  card. 

The  Code  Auditor  will  reference 
this  file  with  a logical  unit 
designator  of  5. 

This  is  the  option  card  input  to 
the  Code  Auditor.  See  3.1.2  for 
format  and  content. 

Indicates  that  program  input  data 
immediately  follows  this  card. 

The  Code  Auditor  will  reference 
this  file  with  a logical  unit 
designator  of  13. 

The  user's  source  should  follow 
immediately  the  card,  $ DATA  13. 

Assigns  the  Code  Auditor's  printed 
output  (logical  unit  number  6)  to 
SYSOUT  for  on-line  conversion. 

Indicates  end  of  job  and  must  be 
the  last  '$'  control  card  of  the  job. 
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3.3.2  Source  Input  From  Disk 

The  control  card  sequence  below  shows  the  deck  structure 
necessary  to  execute  with  source  input  from  disk. 


Control  Card 


Description 


$ IDENT  account  no.,  identification 

$ USERID  system  master  catalog  name 

$ EXECUTE  DUMP 

$ LIMITS  05,  40K,  9K,  5K 

$ PRMFL  H*,  permit,  mode,  file  string 

$ FILE  11,  A3RR,  1L 

$ DATA  05 

CAOPTION  parameters 
$ FILE  13,  device  name,  access 


$ SYSOUT  06 

$ ENDJOB 


See  3.3.1 


See  3.1.2 

Identifies  the  disk  file 
containing  the  user's 
source  code.  Except  for 
the  file  code  of  13,  all 
other  parameters  are  user 
supplied.  See  1.2  (1 ) . 

See  3.3.1 

ll  II 
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3.3.3  Source  Input  From  Tape 

The  control  card  sequence  below  shows  the  deck  structure 
necessary  to  execute  with  source  input  from  tape. 


Control  Card 


Description 


$ I DENT  account  no.,  identification  See  3.3.1 

$ USERID  system  master  catalog  name  " " 

$ EXECUTE  DUMP  " " 

$ LIMITS  05,  40K,  9K,  5K  11  " 

$ PRMFL  H*,  permit,  mode,  filing  string  " " 

$ FILE  11,  A3RR,  1L  " 11 

$ DATA  05  " " 

CA0PTI0N  parameters  See  3.1.2 

$ TAPE  13,  device  name,  multireel  See  3.3.1 


indicator  Assigns  a tape  unit  to 

the  users  input  source 
code.  Except  for  the 
file  code  of  13,  all 
other  parameters  are  user 
supplied.  See  1.2  (1 ). 


$ SYSOUT  06  See  3.3.1 

$ ENDJOB  " '• 
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APPENDIX  A 


RADC  FORTRAN  CODE  AUDITOR  CODING  STANDARDS 


A brief  description  of  the  standards  incorporated  in  the  current  version 
of  the  RADC  FORTRAN  Code  Auditor  Program  follows: 

1 Not  used 

2 Stmt  labels  are  to  be  in  columns  2-5,  right  justified 

3 Stmt  labels  are  to  be  in  ascending  order 

4 Continuation  stmts  to  be  sequenced:  1-9,  A-J 

5 Not  used 

6 Maximum  of  100  executable  statements  per  routine 

7 Not  used 

8 Use  integer  subscripts  when  referencing  an  array 

9 DATA  stmts  to  precede  executable  code 

10  One  type  specification  for  a variable  name 

11  Arguments  in  CALL  stmts  must  not  contain  arith,  or  logical 
expressions 

12  Real  time  routines  may  not  have  arguments  in  CALL  stmts 

13  One  assignment  statement  per  line 

14  No  mixed  mode  arithmetic  on  right  de  of  equal  sign 

15  Whole  numbers  used  as  exponents  t-. c be  integer 

16  Not  used 

17  Not  used 

18  DO  loop  nests  must  not  exceed  six  levels 

19  FORMATS  are  placed  after  I/O  statements,  or  after  RETURN 

20  Not  utilized 

21  Not  utilized 

22  I/O  devices  must  be  referred  to  by  integer  variable  name 

23  Computed  GOTO  stmts  allowed  if  GOTO  variable  is  checked 

24  COMMON  block  length  must  be  same  in  all  modules 

25  All  COMMON  blocks  will  be  labeled 

26  Never  omit  array  subscripts  except  in  DATA,  CALL  or  output  statements 

27  STOP  and  PAUSE  stmts  not  allowed  in  real-time  programs 

28  Assigned  GOTO  stmts  are  not  allowed  in  real-time  programs 

29  Not  used 

30  Not  used 

31  Preface  commentary  block  to  contain: 

C or  * in  column  1 on  all  cards 

First  card:  * in  cols  2 or  3 thru  71  or  72 

Intermediate  cards:  Same  symbol  in  col  1 as  first  card  followed 

by  text 

Last  card:  * in  same  columns  as  first  card 
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32A  Comments  must  precede  blocks  of  one  or  more  IF  stmts 

32B  Conments  must  precede  blocks  of  one  or  more  CALL  stmts 

32C  Comments  must  precede  blocks  of  one  or  more  I/O  stmts 

320  Comments  must  precede  mixed  mode  assignment  stmts 

33  In-line  comments  consist  of  three  or  more  cards: 

C or  * in  column  1 on  all  cards 
First  card:  Blanks  in  cols  2-72 

Intermediate  cards:  Text 

Last  card:  Blanks  in  cols  2-72 

34  No  RETURN  stmt  can  contain  an  argument  list 

35  Not  used 

36  Not  used 

37  Not  used 

The  following  are  the  reasons  for  the  standards  enforced  by  the  Code 

Auditor.  Numbers  correspond  to  the  list  of  standards. 

2)  This  restriction  is  enforced  to  ensure  better  readability  in  source 
code  and  forces  a consistency  in  all  programs. 

3)  Placing  statement  labels  in  ascending  order  will  force  the  code 
to  be  more  readable  by  using  labels  to  sequentially  illustrate 
the  routine/subroutine.  Developers  are  also  encouraged  to  use 
statement  labels  for  illustrating  specific  "blocks"  or  "loops"  in 
code,  (e.g.,  use  order  of  magnitude  of  statement  label  numbers 
to  illustrate  "loops"  or  "blocks"). 

4)  This  restriction  is  enforced  to  ensure  better  readability  in  source 
code  and  forces  a consistency  in  all  programs. 

6)  This  restriction  enforces  the  philosophy  of  modular  programming. 

8)  This  restriction  prevents  mixed  mode  processing  of  array  subscripts. 

This  also  prevents  octal  or  fixed  point  indexing  which  is  prone  to 
error. 
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9)  DATA  specification  statements  are  placed  here  to  secure  a uniform 
location  in  routine/subroutine  code  where  data  specifications  may 
be  found.  Placing  DATA  specification  statements  here  also  ensures 


that  they  will  not  be  placed  after  executable  code. 

10)  This  restriction  facilitates  readability.  This  practice  also 
prevents  redefinition  of  specifications  from  conflicting. 

13)  This  restriction  enhances  readability  and  eliminates  confusion. 

14)  Mixed  mode  is  inefficient  because  it  forces  a penalty  in  execution 
time  to  make  mixed  mode  conversions. 

15)  Integer  exponentiation  is  used  throughout  to  preserve  accuracy 
in  potential  conversion  roundoff  errors. 

18)  This  results  in  inefficient  code  because  the  compiler  will  not 
optimize  code  nested  this  deep. 

19)  FORMAT  statements  are  placed  at  this  position  to  define  a uniform 
location  in  all  code  where  FORMATS  referenced  from  I/O  statements 
may  be  found. 

22)  This  restriction  is  enforced  to  prevent  mode  processing  of 

I/O  statements.  Reference  by  variable  name  allows  easy  change  in 
program. 

23)  This  restriction  forces  'computed  GO  TO'  usages  to  be  completely 
bounded  logically  and  aid  in  ease  of  reading. 


-38- 


■ 


24)  This  restriction  ensures  proper  correspondence  in  COMMON  block. 

25)  All  COMMON  blocks  in  code  are  labeled  to  avoid  the  risk  and 
confusion  of  misinterpretation  of  data  base  locations. 

26)  This  is  enforced  to  keep  flexibility  in  the  processing  of  array 
subscript  operations. 

27)  STOP/PAUSE  statements  are  not  allowed  in  real-time  programming. 

28)  The  philosophy  behind  structured  programming  is  that  it  encourages 
more  efficient  code  due  to  less  branching  and  jumping  to  different 
places  in  code.  This  restriction  is  intended  to  enforce  this 
philosophy. 

31)  This  standard  is  enforced  to  ensure  a consistency  in  preface 
commentation  of  all  programs. 

32)  Comments  must  precede  "IF"  tests,  branch  to  statements,  input/output 
statements  and  statements  containing  statement  labels  to  flag 

and  define  significant  portions  of  the  source  code.  This  practice 
will  also  force  better  documentation. 

33)  This  restriction  is  enforced  to  keep  commentation  in  the  body 
of  routine/subroutine  code  consistent  in  all  programs. 

34)  RETURN  statements  do  not  contain  argument  lists.  Orderly  subprogram 
exits  are  enforced. 


APPENDIX  B 


STRUCTURED  PROGRAM  REQUIREMENTS 


This  appendix  defines  what  is  meant  by  the  term  "structured 


program"  and  describes  the  analytical  methods  employed  by 
the  Code  Auditor  in  exaning  a user's  source  code  for  adherence 


to  "structured  program"  requirements. 


E.l  Program  Segmentation 


The  initial  step  taken  in  determining  whether  a program 
module  adheres  to  "structured  program"  requirements  involves 
the  syntactical  analysis  of  each  of  the  module's  source 
statements. 


This  examination  results  in  an  identification  of  the  logical 
structure  of  the  module  and  its  constituent  parts  (segments). 

A segment,  for  our  purposes.  Is  defined  as  a sequence  of 
statements  with  one  'entry'  statement  and  one  'exit'  state- 
ment (which  may  or  may  not  be  the  same  statement),  such  that 
if  the  'entry'  statement  in  the  sequence  Is  executed,  all 
statements  in  the  set  are  executed;  the  'exit'  statement 
being  executed  prior  to  the  transfer  of  execution  control  to 
another  segment.  Thus,  In  the  sequence  of  source  statements 
which  follow,  the  group  of  statements  between  the  expression 
A=B,  and  the  'predicate'  portion  of  the  IF  expression, 
inclusive,  would  comprise  a single  segment  (assigned  a segment 


identification  code  of  1). 


5 A=B 
B=B+1 .2 

IF  (A  .EQ.  C)  GO  TO  20 
C = C - 1.5 


B * A+B+C 
20  A = A+1.0 

Segment  transfer  may  then  be  defined  as  the  passing  of 
execution  control,  either  implicitly  or  explicitly,  from 
one  segment  to  another.  In  the  preceding  example,  the  state- 
ment IF  (A.EQ.C),  implicitly  passes  execution  control  to  the 
statement  GO  TO  20  (assigned  a segment  identification  code  of 
2),  if  the  'IF'  condition  is  'TRUE',  otherwise  implicit  transfer 
is  made  to  the  statement  OC-1.5  (segment  identification  code 
is  3).  The  'GO  TO'  statement  explicitly  passes  execution  con- 
trol to  the  statement  labelled  '20'  (assigned  a segment 
identification  code  of  4).  It  should  be  noted  that  the  state- 
ment GO  TO  20,  is  a one  statement  segment,  i.e.,  comprises  both 
the  'entry'  and  'exit'  statements  of  segment  no.  2. 

In  order  to  automatically  identify  a program  module's  segments, 
a segment's  entry  statement  must  be  defined  in  a completely 
unambiguous  manner.  A source  statement  is  defined  as  a segment 
'entry'  statement  If: 
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(1) 


it  is  the  first  executable  statement  of  a program 
module. 


(2)  it  is  the  first  executable  statement  following  a 
FORTRAN  ENTRY  statement. 

(3)  it  is  the  first  executable  statement  following  a 
subroutine  CALL  statement. 

(4)  it  is  the  first  executable  statement  following  a 
logical  or  arithmetic  IF  statement. 

(5)  it  contains  a FORTRAN  label  (FORMAT  statements 
excepted)  whether  referenced  or  not. 

(6)  it  is  a DO  statement. 

(7)  it  is  the  first  executable  statement  following 
a DO  terminator. 

(8)  it  Is  the  'consequent'  statement  of  a logical 
IF  statement. 

Similarly  a source  statement  is  defined  as  a segment  'exit' 
statement  if: 

(1)  It  is  an  unconditional  GO  TO  statement. 

(2)  it  is  a computed  GO  TO  statement. 

(3)  it  is  an  assigned  GO  TO  statement. 

(4)  it  is  an  arithmetic  IF  statement. 


(5)  it  is  the  'predicate1  portion  of  a Topical  IF 


1 


statement. 

(6)  it  is  a CALL  to  an  external  routine. 

(7)  it  is  a RETURN  statement. 

(8)  it  is  a STOP  statement. 

(9)  it  is  the  terminal  statement  of  a DO  loop. 

(10)  it  is  any  other  executable  which  precedes  an 
segment  'entry'  statement. 

E.2  Segment  Transfer  Table 

Upon  completion  of  program  module  syntactical  analysis  and 
identification  of  the  module's  logical  segments,  the  Code 
Auditor  builds  a table  which  describes  the  interrelationship 
of  these  segments.  There  is  one  table  per  program  module 
processed.  Describing  the  interrelationship  among  a program 
module's  segments  simply  means  the  'from-to'  pairing  of  segment 
identification  codes  involved  in  the  transfers  of  execution 
control,  thus  the  table  name  'Segment  Transfer  Table'.  The 
Segment  Transfer  Table  shown  below  depicts  the  segment  inter- 
relationships of  the  example  program  statements  of  Section  B.l. 


FROM  TO 

1 2 

1 3 

2 4 

3 4 


The  reader  may  verify  the  authenticity  of  the  over-simplified 
example. 


B.3  Structural  Analysis 


To  begin  our  definition  of  a "structured  program"  consider  the 
coding  structures  shown  in  Figure  B-l . A "structured  program" 
may  contain  a combination  of  only  those  code  structures 
depicted  in  Figure  B-l,  such  that  control  flows  from  top  to 
bottom  or  from  beginning  to  end.  Back-tracking  is  not  allowed. 
To  check  if  a program  module  complies  with  "structured  program" 
reguirements,  the  Code  Auditor  iteratively  applies  a reduction 
algorithm  to  the  module's  corresponding  Segment  Transfer  Table 
until  the  residual  table  is  irreducible.  If  the  residual  table 
contains  more  than  one  entry,  then  the  module  is  unstructured. 
The  algorithm  steps  are  as  follows: 

(1)  Delete  all  trivial  entries;  entries  of  the  form 
(i  »i ) 

(2)  Delete  all  redundant  entries;  entries  of  the  form 
(1»j)  except  the  first 

(3)  If  i transfers  to  j and  either 

(a)  j only  transfers  to  k for  some  k 
or 

(b)  i only  transfers  to  j 

Then:  replace  j with  i 
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STRUCTURAL  ANALYSIS  COOING  STRUCTURES 


METRIC  SYSTEM 


BASE  UNITS: 


Quantity^ 

Unit 

SI  Symbol 

Formula 

length 

metre 

m 

mass 

kilogram 

kg 

time 

second 

s 

electric  current 

ampere 

A 

thermodynamic  temperature 

kelvin 

K 

amount  of  substance 

mole 

mol 

luminous  intensity 

candela 

cd 

SUPPLEMENTARY  UNITS: 

plane  angle 

radian 

rad 

solid  angle 

steradian 

»r 

DERIVED  UNITS: 

Acceleration 

metre  per  second  squared 

m/s 

activity  |of  a radioactive  sourrel 

disintegration  per  second 

(disintegration  )/s 

angular  acceleration 

radian  per  second  squared 

rad/s 

angular  velocity 

radian  per  second 

rad/s 

area 

square  metre 

m 

density 

kilogram  per  cubic  metre 

kg/m 

electric  capacitance 

farad 

K 

A-s/V 

electrical  conductance 

siemens 

S 

A/V 

electric  field  strength 

volt  per  metre 

V'm 

electric  inductance 

henry 

H 

V-s/A 

electric  potential  difference 

volt  ' 

V 

W.'A 

electric  resistance 

ohm 

V/A 

electromotive  force 

volt 

V 

W/A 

energy- 

loule 

1 

N-m 

entropy 

joule  per  kelvin 

1* 

force 

newton 

N 

kg-m/s 

frequency 

hertz 

Hz 

(cycle  )/s 

illuminance 

lux 

lx 

lm/m 

luminance 

candela  per  square  metre 

cd/m 

luminous  flux 

lumen 

Im 

cd-sr 

magnetic  field  strength 

ampere  per  metre 

Aim 

magnetic  flux 

weber 

VVb 

Vs 

magnetic  flux  density- 

tesla 

T 

Wb/m 

magnetomotive  force 

ampere 

A 

power 

watt 

W 

i/s 

pressure 

pascal 

Pa 

M/m 

quantity  of  electricity 

coulomb 

c: 

A-s 

quantity  of  heat 

joule 

1 

N-m 

radiant  intensity- 

watt  per  steradian 

W/sr 

specific  heat 

joule  per  kilogram-kelvin 

I'kg-K 

stress 

pascal 

Pa 

N/m 

thermal  conductivity 

watt  per  metre-kelvin 

Wim-K 

velocity 

metre  per  second 

mis 

viscosity,  dynamic 

pascal-second 

Pa-s 

viscosity,  kinematic 

square  metre  per  second 

mis 

voltage 

volt 

V 

W/A 

volume 

cubic  metre 

m 

wavenumber 

reciprocal  metre 

(wave|/m 

work 

joule 

f 

N-m 

SI  PREFIXES: 


Multiplication  Factors 


Prolix  SI  Symbol 


1 000  000  000  000  = 10” 

tnra 

T 

t 000  000  000  = 10’ 

gig* 

<; 

1 000  000  = 10* 

mega 

M 

1 000  = 10» 

kilo 

k 

100  = 10» 

hecto* 

h 

10  = 10’ 

delta* 

da 

0.1  = 10-' 

decl* 

d 

0.01  = 10- 1 

centl* 

i: 

0001  = 10-' 

milli 

m 

0.000  001  = 10-* 

micro 

/* 

0 000  000  001  - 10- ’ 

nano 

n 

0.000  000  000  001  = 10-  ” 

pico 

P 

0.000  000  000  000  001  = 10- " 

femlo 

F 

0.000  000  000  IKK)  IKK)  001  = I0~  '• 

atto 

a 

* To  be  avoided  where  poeeible. 
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